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A human-in-the-loop simulation was conducted to investigate the operational feasibility, 
technical requirements, and potential improvement in airspace efficiency of adding a 
Multi-Sector Planner position. A subset of the data from that simulation is analyzed here 
to determine the impact, if any, of ground-ground data communication (Data Comm) on 
verbal communication and coordination for multi-sector air traffic management. The 
results suggest that the use of Data Comm significantly decreases the duration of 
individual verbal communications. The results also suggest that the use of Data Comm, 
as instantiated in the current simulation, does not obviate the need for accompanying 
voice calls. 


INTRODUCTION 

The Next Generation Air Transportation System 
(NextGen) concept developed by the Joint Planning 
and Development Office outlines a transformation 
of air traffic management from the current system to 
one in which traffic is managed in a much more 
strategic fashion. Development of new 
technologies, such as digital data communication, 
better aircraft surveillance, and automation- 
supported conflict detection and resolution, is 
expected to support the transformation to trajectory- 
based operations. It also provides an opportunity to 
explore new team configurations that may better 
take advantage of the new technologies by 
reallocating the roles and responsibilities among the 
various air traffic service providers. 

One concept under consideration modifies the 
standard team configuration within an air traffic 
facility (e.g. controllers, Area Supervisors, Traffic 
Management Coordinators, etc.) to include a new 
position called Multi-Sector Planner (MSP). There 
have been numerous investigations in the U.S. and 
Europe (Herr, Teichmann, Poppe, & Sharez, 2003) 
exploring different variants on the MSP position 
with the common assumption that in the future air 
traffic environment aircraft trajectories can be 
strategically managed across multiple sectors. 

The current investigation of the MSP position 
by the Federal Aviation Administration examines 
the MSP who performs the functions often 
associated with traffic flow management but works 
the traffic at a much closer time horizon and by 


manipulating individual aircraft trajectories. In this 
concept, the MSP assists with trajectory and flow 
management functions by assessing traffic 
complexity and flows across several sectors and 
within an effective planning timeframe between 
approximately 30-60 minutes and then rerouting 
aircraft to manage the complexity and/or redirect 
the flows around traffic constraints (e.g., weather 
cells). Working at a time horizon less immediate 
than that of the sector controller but closer in time 
than the Traffic Management Unit, the MSP has the 
potential to reduce delays and provide more 
efficient route options when aircraft must be re- 
routed. 

A large-scale human-in-the-loop simulation 
investigating the operational and technological 
requirements and feasibility of the MSP concept 
was carried out in 2009. The current study examines 
a subset of the data from the larger simulation, 
namely, the verbal and data communication and 
coordination between MSPs and a Traffic 
Management Coordinator (TMC). 

Rationale for the Current Study 

One of the key feasibility questions for the MSP 
concept has been whether the extra coordination 
layer, created by adding MSP positions to the 
existing team configuration, would result in an 
unmanageable amount of required coordination. 
Given that one of the main MSP functions is to 
create and send 4-D trajectory reroutes, we 
hypothesized that the availability of ground-ground 



digital data communication (Data Comm) that can 
send and receive route trajectories would offload 
verbal communication and coordination, thus 
increasing feasibility. 

There are several features of Data Comm, in 
particular the ability to create and send graphical 4- 
D trajectory reroutes on one or more aircraft, which 
may be suited to facilitating verbal communication. 
For one, the visual modality is particularly useful 
for spatial communication. Verbally describing 4-D 
trajectories, particularly those based on lat/long 
coordinates and not restricted to pre-defmed VORs, 
waypoints, or fixes, can be cumbersome at best. 
Having a common visual reference might also 
reduce the number of miscommunications and 
consequent verbal clarifications. Further, the use of 
Data Comm tools like those in the current study can 
facilitate the aircraft identification process by 
providing immediate visual feedback on the aircraft 
and routes that have been sent, thereby eliminating 
the typical pause in verbal communications while 
one party searches for the target aircraft. 

In this study, we asked participants to verbally 
coordinate trajectory/flow plans with everyone 
impacted by the plan. Given this procedure. Data 
Comm was not likely to significantly reduce the 
total number of coordination requests, but it could 
reduce the duration of verbal communications. 
Therefore, we hypothesized and tested whether 
voice communications supported by Data Comm 
were shorter than those not supported by Data 
Comm. 

METHOD 

The data reported here are taken from a larger 
study conducted in 2009, a description of which is 
beyond the scope of the current report; only the 
relevant methods are described here. A 
comprehensive report on the simulation in its 
entirety is currently in preparation. 

Simulation Facilities 

The study took place in the NASA Ames 
Research Center Airspace Operations Laboratory 
(AOL) using the Multi- Aircraft Control System 
(MACS) simulation platform (Prevot et ah, 2006). 
MACS has been used to quickly prototype NextGen 


functions to support numerous concept evaluation 
simulations. All of the basic controller functions for 
today’s operations are available in MACS but it also 
augments the displays to include anticipated 
NextGen functions such as conflict probe and Data 
Comm. 

In order to support the MSP study, MACS 
displays were expanded further to include a suite of 
MSP tools. This prototype workstation included a 
Traffic Situation Display with predicted weather 
information and an interactive display which could 
be used to filter aircraft, construct routes, and 
coordinate the routes with others. The MSP 
workstation also provided tabular and graphical 
displays of current and predicted load and 
complexity for all sectors within each MSP’s 
Center. The prototyped tools provided, among other 
functions, the ability for graphical and/or keyboard 
user input multi-aircraft selection and trial route 
planning in an advanced operational air traffic 
management environment. 

Most relevant to the current report, these tools 
allowed MSPs, TMCs, and Area Supervisors (Sups) 
to create new 4-D reroute plans for one or more 
aircraft and to communicate these plans to other 
MSPs, TMCs, Sups, and controllers via Data 
Comm. Additionally, a Voice Communication 
System (VCS) emulation allowed for verbal point- 
to-point and progressive conference calls between 
positions. 

Training and Study Design 

The MSP team participated in 4 days of training 
on the concept, operational procedures, and use of 
the tools and VCS. The data were collected over 2 
full days of simulation, each consisting of 4, 75- 
minute runs. The simulation runs alternated 
between high traffic loads and convective weather 
problems. 

The simulated airspace, staffed by four MSPs 
and one TMC, consisted of high altitude airspace of 
Kansas City Center (ZKC) and part of Memphis 
Center (ZME). The traffic and weather scenarios 
were designed to put the most pressure on the 
eastern half of ZKC. Therefore, eastern ZKC was 
split into a north and south half and assigned to one 
MSP each while western ZKC and northeastern 


ZME were each assigned an MSP. The TMC’s 
purview was all of ZKC. 

MSP participants were instructed to monitor the 
30-60 minute time horizon traffic situation and 
sector complexity within their respective areas of 
responsibility to ensure that controller workload 
remained within safe and manageable levels. If they 
determined reroutes were needed, they were asked 
to coordinate with each other, the Sups, and the 
TMCs as necessary, using the tools to plan, 
coordinate, and execute these reroutes. For the 
current purposes, ZKC TMC’s role was similar 
though based on a further time horizon and also 
included maintaining the “big picture” and 
coordinating high-level plans. 

For simplicity, communications with a second 
TMC, played by a confederate participant, are not 
included in this analysis. Communications with the 
Area Supervisors are also excluded from 
consideration here because they were of a 
substantially different nature, (e.g., per protocol, 
one Supervisor never received or sent Data Comm). 

Participants 

The relevant participants then were two Front 
Line Managers and two Supervisor Traffic 
Management Coordinators (the four MSPs), and a 
Traffic Management Coordinator (ZKC TMC), each 
with over twenty years experience in air traffic 
management. 

RESULTS 

Associating Data Comm with Voice Calls 

In their speech, participants did not 
systematically make explicit reference to the fact 
that they were discussing a plan sent via Data 
Comm. Therefore, we started from the Data Comm 
messages, rather than the voice call transcriptions. 
For each Data Comm sent, the message initiator, 
recipient(s), timestamp, and subject aircraft call 
signs were extracted. Then, voice calls between the 
initiator and at least one recipient that preceded and 
followed the Data Comm by up to 10 minutes were 
checked for references to information contained in 
the Data Comm (e.g., “Hey [MSP] West, SWA364 
just north of Tulsa there, if you could get him down 


to 28,000 feet, [for] complexity in [sectors] 29 and 
90.”). The surrounding ten minute interval was 
chosen because Data Comm messages “timed out” 
and were deleted from the system if not acted upon 
within ten minutes. 

Of the total of 356 Data Comm messages sent 
by TMC and MSPs over 8, 75-minute runs, 285 
(80%) either preceded or followed a related voice 
call, while 66 (18.5%) were not associated with a 
voice call. An additional 5 (1.5%) would have been 
associated with a voice call but had been 
misaddressed, typically due to user typographic 
error. Voice calls pertaining to these last 5 messages 
not were coded as associated with a Data Comm 
message, since the intended recipient never received 
the message. 

The total number of calls associated with Data 
Comm messages was 244. This number differs from 
the number of Data Comm messages associated 
with calls (285) because some calls covered 
multiple Data Comm messages at the same time. In 
234 (96%) cases, at least one of the related Data 
Comm messages (if there were multiple associated 
with the call) was sent before the voice call was 
placed, and on average the voice call followed the 
Data Comm by about 30 seconds (M = 28.9 s, S.D. 

= 15.3 s). 

Data Comm-Supported Voice Calls 

Given that conference calls were in general 
longer and were not often associated with Data 
Comm, we decided to only consider dyadic calls. 
We further narrowed our dataset to include only 
calls between MSPs or between an MSP and the 
TMC. Out the remaining 267 voice calls then, 135 
(50.6%) pertained to a Data Comm message and 
130 of those followed the Data Comm. 

On average, calls that were preceded by Data 
Comm were significantly shorter that those that 
were followed by or unassociated with Data Comm 
(Ns = 130 and 137, Ms = 28.4 s and 38.3 s, S.D.s = 
15.9 s and 21.7 s, respectively; F( 1,266) = 17.89, p 
< .001; Fig. 1). 

Because the TMC sent many fewer Data Comm 
messages than the MSPs and might be expected to 
hold longer voice calls due to the greater scope of 
his responsibilities, we also decided to look at just 
MSP to MSP calls. Again, calls that were preceded 



by Data Comm were shorter that those that were 
followed by or unassociated with Data Comm (Ns = 
97 and 51, Ms = 24.3 s and 29.2 s, S.D.s = 10.0 s 
and 16.4 s, respectively; F(1 , 147) = 5.22, p < .05; 
Fig. 1). 



MSP-MSP and MSP-MSP 

MSP-TMC Calls Calls Only 


Figure 1. Mean voice call duration for dyadic calls that were 
preceded by and pertained to Data Comm and that were 
followed by or unassociated with any Data Comm. Error bars 
represent standard error of the mean. 


DISCUSSION 


Most MSP-MSP communication and 
coordination was carried out with the help of Data 
Comm. Consistent with their training, downstream 
MSPs tended to identify a predicted traffic or 
weather problem in their area of responsibility, 
develop a set of reroutes to solve the problem, and 
send those proposed reroutes via Data Comm to the 
upstream MSP responsible for the area where the 
subject aircraft were located. Data Comm was 
typically followed by a voice call from the 
downstream MSP to ascertain whether the upstream 
MSP was amenable to the request, would clear the 
request with the upstream Area Sup, and would 
forward the request on to the sector controllers. 

Notably, the use of Data Comm for plan 
coordination decreased subsequent voice call 
length. This is probably in part because the Data 
Comm contained information that would otherwise 
need to be spoken. For example, instead of verbally 
describing a desired route modification, plan 
initiators could simply point recipients to a Data 
Comm. Once the recipient pulled up and viewed the 
graphical representation of the reroute, a simple 
“WilCo” was often all that was required. Data 
Comm also made it was easier for recipients to 
locate the subject aircraft. Rather than typing in one 


or more aircraft call signs to bring up their flight 
data blocks and/or visually searching the display for 
the subject aircraft, the recipient could simply click 
on the received Data Comm message notification 
and thus bring up the 4-D trajectory. 

While Data Comm appears to have facilitated 
communication and coordination, we cannot say 
whether it could have reduced the number of verbal 
communications since our protocol required verbal 
coordination. Consistent with the training we 
provided, the majority of Data Comm messages 
were accompanied by a voice call. One reasonable 
prediction would be that there would be fewer 
verbal communications when Data Comm was 
used, since participants could plan, propose, accept, 
and execute traffic initiatives all via Data Comm. 
However, there is reason to suspect that these 
supplemental voice calls would still have been 
necessary, even if they had not been formally 
required in this simulation. One reason for this is 
that it was not possible to embed the reason for a 
reroute request in the Data Comm itself. Another is 
that although participants could accept or deny 
requests via Data Comm, they could not embed an 
explanation for their acceptance or denial. Had 
participants been able to send their reasoning along 
with their request or response, perhaps with a brief 
text annotation like “To avoid Wx in ZKC 94” or 
“Reroute traverses overloaded ZME 25,” fewer 
voice calls might be necessary. 

Another reason voice calls might have been 
necessary even with Data Comm, is because verbal 
conversation may have been more conducive to 
active negotiation. In its current instantiation, 
proposed 4-D reroutes sent via Data Comm needed 
to be accepted “as is” or denied. Participants did not 
have the option of modifying received reroutes, 
although they could chose to select and approve 
only certain reroutes out of a group received 
together. Therefore, verbal communication was 
needed so that the plan initiator could learn why his 
plan was rejected and what alternative reroute 
options were available to solve his traffic problem. 
One solution to these required voice calls might be 
to allow the Data Comm recipient to alter the 
reroutes in a way that works for his area and to send 
the modified Data Comm back to the original 
initiator for final sign-off. Again, it would be 
helpful if the recipient could know via Data Comm 


what problem the reroutes were originally meant to 
solve. 

Overall, the study suggests that Data Comm 
may offload verbal communication and 
coordination of reroute plans. While voice calls may 
not decrease in number, they decrease in length 
when preceded by Data Comm. Additional 
enhancements, some relatively minor, to the 
currently prototyped AOL Data Comm capabilities 
may further decrease the amount of verbal 
coordination required. It must be noted though that 
the current study was merely correlational and not 
an experiment proper, since access to Data Comm 
was not manipulated. Future research examining in 
a controlled manner the impact on verbal 
communication and coordination of the availability 
of Data Comm is warranted. 
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